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(54) Client/server protocol for proving authenticity 



(57) A protocol for establishing the authenticity of a 
client to a server in an electronic transaction by encrypt- 
ing a certificate with a key known only to the client and 
the server. The trust of the server, if necessary, can be 
established by a public key protocol. The client gener- 



ates and sends over a communications channel a mes- 
sage containing at least a part of a certificate encrypted 
with the server's public key or a secret session key The 
server receives and processes the message to recover 
at least part of the certificate, verifies and accepts it as 
proof of the client's authenticity 
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Description 

The invention relates to a protocol for one party to 
an electronic transaction, as for example a client in a 
client-server transaction, to prove its authenticity to the 
other party of the transaction. 

BACKGROUND OF THE INVENTION 

Client-server systems provide electronic access by 
the client to data, information, accounts and other ma- 
terial stored at the server In financial transactions, the 
system provides a client electronic access to accounts 
and financial resources. 

In a client-server transaction, the client is required 
to prove to the server that it is an authentic client, and 
not some impersonator or other unauthorized party. Pro- 
tocols are known by which a client proves to a server its 
authenticity, while at the same time it does not reveal 
information that could be misused by a third party. 

A standard well known protocol for proving authen- 
ticity involves public-key cryptography. The client estab- 
lishes a public key/private key pair and provides the pub- 
lic key to the server. In a transaction, to prove its authen- 
ticity to the server, the client forms a digital signature 
with its private key on a time-varying message, and the 
server verifies the digital signature with the client's pub- 
lic key. The time-varying message, which may be a 
timestamp or a challenge supplied by the server, is dif- 
ferent in each instance This message, when checked 
by the server, provides safeguards against a third party 
impersonating the client by simply replaying copies of 
previous signatures of the client that the third party has 
intercepted or otherwise acquired. 

In the standard protocol described above, the serv- 
er trusts that the public key belongs to the client, i.e., 
that the client is in fact actively involved in the transac- 
tion because it is presumed that only the client knows 
the private key and can form valid digital signatures. A 
convenient way to establish trust in a public key is to use 
a certificate. This is accomplished by a certification au- 
thority issuing public-key certificates signed with the cer- 
tification authority's private key, which thereby asserts 
to the server that the client's public key is a valid public 
key issued by or registered with the certification author- 
ity. Assuming the server trusts the certification authori- 
ty's public key, then it trusts the client's certificate, the 
client's public key and ultimately the client's authenticity. 

With typical public-key cryptosystems, it is compu- 
tationally expensive to form digital signatures because 
of the need to perform an exponentiation operation. In 
some electronic transactions, for example, those involv- 
ing a smart card client where the computational capacity 
is limited, the standard protocol using a digital signature 
is computationally expensive and is therefore a signifi- 
cant burden. 

Beller and Yacobi, in an article entitled "Fully- 
Fledged Two-Way Public Key Authentication and Key 
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Agreement for Low-Cost Terminals" ELECTRONICS 
LETTERS, May 27, 1993, Vol. 29, No. 11, at pages 
999-1000, describe a protocol that provides for less on- 
line computation on one side of the protocol. In this pro- 
tocol authentication of the server by the client is carried 
out by the server sending a random challenge with an 
expected "colour", structure or format, to the client for 
verification by the client. Authentication of the client by 
the server is achieved by the client sending to the server 
its identity, public key, certificate and a signature on the 
random challenge for verification of the certificate and 
the signature by the server The protocol is described 
as being useful where one side of the interaction is a 
low-cost customer device such as portable telephones, 
home banking terminals, smart cards and notebook 
computers. 

Other protocols are known for establishing the au- 
thenticity of a client to a server Client authentication 
protocols such as those based on secret-key cryptogra- 
phy exist, but often have the limitation that the server 
must be on-line, or the server must store a key which 
can be used to impersonate arbitrary clients. In Cellular 
Digital Packet Data systems, a client authenticates itself 
to a server by sending a one time password encrypted 
with a Diffie-Hellman shared key, and the server returns 
a new password for the next session. Again, the server 
must be on-line or the client must share a different pass- 
word with each server, which can be inconvenient. 



30 BRIEF DESCRIPTION OF THE INVENTION 



A protocol that is less computationally expensive for 
a client but achieves similar goals as the standard pro- 
tocol is used to develop a server's trust in the client. In 
this protocol, a certificate provided by a trusted certifi- 
cation authority to the client is encrypted with a key 
known only to the client and the server or the public key 
of the server The client forms no digital signature. Since 
only the client and the server it trusts have access to the 
certificate, the certificate itself is proof of the authenticity 
of the client. This protocol is particularly useful in client 
devices having small computational capacity, e.g.. a 
smart card. 

Additional interactive protocols are disclosed 
whereby messages are exchanged between client and 
server to establish authenticity of both the client and the 
server as well as protocols wherein only a portion of the 
client's certificate is encrypted. Moreover, the certificate 
can include a one way function, such as a cryptographic 
hash function of a secret value or a root of a hash tree 
of secret values for protection against the certification 
authority or unauthorized servers, respectively. 

A still further more general protocol involves a user, 
which may be an individual, a computer or some other 
entity, connected to a verifier by way of an encrypted 
communications channel such that the user can confi- 
dentially deliver to the verifier information essential to 
verify the message. 
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DESCRIPTION OF THE DRAWINGS 

Figure 1 schematically illustrates the components 
of a smart card; 

Figure 2 illustrates the components of a server; 

Figure 3A is a flow diagram showing the procedure 
for generating messages by a client to prove its au- 
thenticity to a server; 

Figure 3B is a flow diagram showing the processing 
at the server of messages sent by a client to authen- 
ticate the client; 

Figure 4A is a flow diagram illustrating an interactive 
embodiment of the invention where the server 
sends a copy of its certificate to a client; 

Figure 4B is a flow diagram illustraling an interactive 
embodiment of the invention where the server 
sends a copy of its certificate and a time-varying val- 
ue to the client; 

Figure AC is a flow diagram illustrating an interac- 
tive embodiment of the invention where the server 
sends a time-varying value to the client; 

Figure 5 is a flow diagram illustrating an interactive 
embodiment of the invention where a client is sent 
a message signed by the server; 

Figure 6 is a partial flow diagram illustrating a vari- 
ation in the messages generated by the client; 

Figure 7 is a partial flow diagram illustrating a ver- 
sion of the invention where a client's certificate is 
sent directly to a server; 

Figure 8 is a partial flow diagram of Figure 5 modi- 
fied so that only part of the client's certificate is en- 
crypted; 

Figure 9 is a partial flow diagram of Figure 6 modi- 
fied so that only part of the client's certificate is en- 
crypted; 
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Figure 10 is a partial flow diagram of Figure 7 mod- 
ified so that only part of the client's certificate is en- 
crypted; so 

Figure 1 1 is an illustration of a hash tree which may 
be used to prevent misuse by a server; and 

Figure 12 illustrates a still further flow diagram of 55 
essential elements of a system having a more gen- 
eral protocol but which may have features of other 
embodiments disclosed herein added thereto. 



DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The specific description of the invention is set forth 
in the environment of a smart card client. However, the 
invention is not limited to a smart card client since the 
disclosed protocols are applicable to client/server sys- 
tems in general, and in particularclients having low com- 
putational capacity such as portable telephones, note- 
book computers and home banking terminals. In an 
even more general manner the disclosed exemplary 
embodiments as described later can involve a user, 
which can be an individual, a computer or some other 
entity, which is connected to a verifier, which can be a 
client, a server or some other entity, via an encrypted 
communications channel whereby the user can confi- 
dentially deliver to the verifier information essential to 
verify the message. 

A smart card includes a microchip containing a 
processor and memories to hold programs and data. 
Figure 1 illustrates a smart card 1 comprising a proces- 
sor 2. an erasable programmable read only memory 
(EPROM) 3, programmable read only memory (PROM) 
4, random access memory (RAM) 5, input/output (I/O) 
port 6, number generator 7, clock B and power source 
9. PROM 4 holds the card operating system and RAM 
5 holds temporary results of calculations. EPROM 3 
holds the certificate for the card. This certificate for the 
card, unlike the usual public key certificate, need not in- 
clude the public key of the client since authentication of 
the client by the server does not rely on the public key 
of the client. A cache of public keys of one or more serv- 
ers may also be stored in PROM 4 or EPROM 3. Number 
generator 7 provides random seed numbers to the proc- 
essor for generating secret session keys. Clock 8, con- 
ventional and well known in the art, is used for generat- 
ing a timestamp and for verifying a received timestamp. 
Clock 8 is optional where the sen/er's timestamp or time- 
varying value is used by the client to provide a time-var- 
ying value or where a challenge procedure is followed. 
Power source 9 is a battery when a card has a clock. 
Otherwise, power may be supplied by an external 
source or a server I/O terminals 6 provide a means for 
external communications. 

The public key of a trusted certification authority 
may be stored in PROM 4 or EPROM 3. PROM 4, or the 
RAM 5 if non-volatile, may have a section for storing cer- 
tificate revocation lists (CRLs). Such a list would include 
a list of servers whose certificates have expired or been 
revoked. This list would be provided by signed and dat- 
ed messages from the trusted certification authority ei- 
ther directly or indirectly while in a communicating rela- 
tionship with a server Reference to the list during the 
initial stages of the protocol will indicate whether the 
transaction being initiated is with a valid server or with 
one holding a revoked certificate, and thereby whether 
a received server's certificate is to be verified. 

The card manufacturer initializes the smart card us- 
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ing conventional techniques. PROM 4 is loaded with an 
operating program to be executed by processor 2, clock 
Sis set (or an initial time-varying value, e.g., asequence 
number or a timestamp is set in one of the memories 
when a clock is not used) and the certificate associated 
with the card andcthe trusted certification authority's 
public key are loaded into the memories. Optionally, 
server public keys and CRLs are also loaded into the 
memories. 

A server 40 as illustrated in Figure 2 includes a proc- 
essor 60, a facility for generating a time-varying value 
or timestamp 42, input/output port 63, and a memory 61 
for holding the operating program for the processor, the 
private key PRIVqerv associated with the server's pub- 
lic key PUBqerv and the public key PUBjca the trust- 
ed certification authority that signed the client's certifi- 
cate. In addition, memory 61 may hold a certificate rev- 
ocation list (CRL) and a certificate (CERT-S) tor its pub- 
lic key. The facility for generating a time-varying value 
42 may comprise a clock for generating a timestamp or 
other means for generating a time-varying value. The 1/ 
O port 63 provides an interface between the processor 
of the server and external entities. 

Figure 3A illustrates the processing by a client for 
generating and sending messages to a server for use 
by the server to prove the client's authenticity. A client 
at 101 generates or provides a time-varying value (TS). 
This may be a timestamp or other value which changes 
with time. The client also generates a random secret 
session key (KSS) at 102 employing a number genera- 
tor or other means to provide a random seed number. 
At step 103. the time-varying value TS and the secret 
session key KSS are concatenated and at 1 04 the result 
is encrypted with the server's public key PUBserv which 
has been retrieved from memory 4 or 5. The encrypted 
message {KSSITS}PUBserv is sent to the serverat 1 07. 
The client's certificate (CERT-C) is retrieved from mem- 
ory, EPROM 3, at 1 05, encrypted with the secret session 
key KSS at 106 to form message {CERT-C}kSS which 
is sent to the server at 108. The sending operations 107 
and 108 may be combined into one operation. 

Figure 3B illustrates the processing at a server 40 
of messages received from a client via I/O port 63 for 
the purpose of ensuring the authenticity of the client. In- 
itially, the server decrypts at 201 the message {KSS(TS) 
P'-^SsERV rising its private key PRI Vs^rv recoveredfrom 
memory 61. At 202 the received time-varying value TS 
is compared with a reference value obtained from the 
server's facility for generating a time-varying value 42. 
Where the values do not compare an error signal is gen- 
erated at 207 and the process is terminated. Where the 
time-varying values compare, the processing continues 
at 203 with recovery of the secret session key KSS and 
at 204 by decrypting of the message {CERT-C}KSS us- 
ing the secret session key. This provides the server with 
the client's certificate (CERT-C) which is then at 205 
subjected to a public key operation using the trusted cer- 
tification authority's public key PUBjca retrieved from 
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memory 61. At 206 a verification of the certificate 
(CERT-C) is performed with the subsequent generation 
at 208 of an error signal where the certificate cannot be 
verified or the generating of an authentic signal at 209 
where the certificate is found to be authentic. The veri- 
fication procedure at 206 may include the use of the CRL 
stored in memory 61 . 

One embodiment of the invention is a non-interac- 
tive version where the protocol requires only the sending 
of messages over a communications channel by a client 
to the server with which it is seeking to execute a trans- 
action. In other interactive embodiments (Figures 4 A, 
48 and 4C), a message, designated 11 in the drawing 
figures, containing information needed by the client to 
produce authenticating messages for the server, e.g., 
the public key of the server and/or a time-varying value 
provided by the server, is sent by the server to the client. 
In a further interactive embodiment (Figure 5), the client 
has need of assurance of the server's presence in the 
transaction and therefore requires a message signed by 
the server. Figure 6 represents a modification of the em- 
bodiments of the invention due to the message gener- 
ated by the client having the time-varying value com- 
bined with the certificate of the client. Figure 7 shows a 
version of the invention where a session key is not used. 
Moreover, Figures 8 to 1 0 illustrate modifications to the 
embodiments of Figures 5 to 7 wherein only a part of 
the client's certificate is encrypted. Additionally, Figure 
12 illustrates a fundamental protocol whereby a user 
can confidentially deliver to a verifier information which 
is essential to verify a message signed by a credential 
issuing authority, but which may be modified to include 
one or more features of other disclosed embodiments. 

In the n on -interactive embodiment, there is no mes- 
sage 11 sent from server 40 to a client in the authenti- 
cation protocol. The protocol is essentially as shown in 
Figures 3A and 3B with a client configuration as in Fig- 
ure 1 and a server configuration as in Figure2. The client 
upon gaining access to a server 40 obtains the server's 
public key from a local storage, generates a random se- 
cret session key KSS (102), concatenates (103) it with 
an internally generated time-varying value, encrypts 
(104) the result with the server's public key and sends 
the result to server 40 (107). The client concurrently or 
subsequently retrieves its certificate (CERT-C) from 
storage (105) encrypts (106) the certificate with the se- 
cret session key and sends the result to server 40 (108). 
In the non-interactive embodiment, there is no signing 
by the server or even the generation and sending of a 
message by the server. The client's confidence in the 
server is assured by the use of the server's public key, 
since only the server can decrypt a message encrypted 
with its public key. The authenticity of the client is estab- 
lished to the satisfaction of the server by its receipt and 
verification of the time-varying value and the client's cer- 
tificate by processing the received messages in accord- 
ance with the procedure shown in Figure 3B. 

In the interactive embodiments of Figures 4A, 4B 
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and 4C. message 11 consists of a certificate (CERT-S), 
a time-varying value, or a combination of a certificate 
(CERT-S) and a time-varying value. These information- 
al items are provided to a client so that the client may 
properly form authenticating message 12. Figure 5 
shows an interactive embodiment where the server pro- 
vides a signed message 11. Since Figure 5 is the most 
comprehensive, it will be described first, and the embod- 
iments of Figures 4A, 4B and AC described primarily 
with respect to differentiating features caused by the dif- 
ferences in the content of message 11 . 

In Figure 5, the parties to the electronic transaction 
are the client 20 and the server 40. Messages 11, 12 
and 1 3 are generated and exchanged between the client 
20 and the server 40 over a communications channel 
15. Successful exchanges ot the messages establish 
the trust of the client 20 in the server 40 and the authen- 
ticity of the client 20 to the server 40. Communications 
channel 15 may simply be electrical connections be- 
tween a card reader and the terminal equipment at a 
server or may be in the form of a telephone or other com- 
munications link established between a client and a re- 
mote server, or other conventional communications me- 
dium. 

Client 20 includes a certificate (CERT-C) 21 stored 
in EPROM 3. a key generator (KEY) 22, a facility for gen- 
erating a time-varying value (TS) 23 which may include 
the clock 8. when used, and the public key {PUBjq^) 24 
of the trusted certification authority which may be stored 
in EPROM 3 or PROM 4. Certificate 21 comprises a 
message provided and signed by the trusted certifica- 
tion authority with its private key in the standard manner 
The message in this instance need not be the client's 
public key because this key is not involved in the proto- 
col. Any message is sufficient and may be certain well 
structured information about the client, e.g., account 
number and expiration date of the account. The mes- 
sage may also indicate the types of transactions for 
which the client 20 is authorized and the period of time 
during which the certificate may be considered valid. 
The key generator 22 is comprised of any conventional 
means of generating an encryption key. It may comprise 
a subroutine in the processor and use a number sup- 
plied by a number generator 7. The facility 23 may com- 
prise conventional clock 8 that provides a current date 
and time or may be one that operates on a received 
timestamp or time-varying value. Key 24. the public key 
of the trusted certification authority, is used lo verify a 
certificate sent by the server and signed by the trusted 
certification authority. 

Key storage unit 25 represents an optional memory 
or memory section for storage of keys of one or more 
frequently used servers. These are the public keys of 
servers and are made available to clients by the servers. 
Storing the public key of server 40 and other selected 
servers at the client avoids the need to process the cer- 
tificate from a server to recover the key, or provides a 
source for the key where the certificate does not contain 
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the public key or an easily recoverable copy of the public 
key of the server CRL storage unit 26. also an optional 
memory or memory section, stores a list of certificates 
that have been revoked. 

Elements 30 through 35 illustrate the functional 
processes of the protocol performed by the client to es- 
tablish trust in the server Public key operations are con- 
ventional well known processes in the art. Recovering 
the public key of the server from the server's certificate 
for the key and storing it in a memory, as illustrated in 
block 30, is a certificate processing within the skill of art. 

Functional element 32 represents a public key op- 
eration performed with the trusted certification authori- 
ty's public key 24 on the certificate portion of the mes- 
sage 11 received from the server 40. Functional element 
31 represents a public key operation performed on the 
timestamp or other time-varying value received from a 
server with the server's public key obtained from 
processing the certificate at read and store element 30 
or from key storage unit 25. At functional block 33 a 
standard verification procedure, as those skilled in the 
art appreciate, is used to verify the certificate. A certifi- 
cate revocation list supplied from memory 26 may op- 
tionally be used in verifying the certificate. 

Functional element 34 represents a comparison 
and verification of the timestamp or time-varying value 
received from the server 40 to verify that it is proper 
Where the smart card or client has a clock, a simple 
comparison (allowing for small time differences) of the 
time at clock 8 with the time of the received timestamp 
suffices to verify a received timestamp. Where the smart 
card does not include a clock, the stored time of a last 
received valid timestamp can be compared with the time 
of the currently received timestamp to verify that the cur- 
rently received timestamp is later in time. Any time-var- 
ying value may be received and processed to verify that 
it is of recent origin or in a proper time sequence. 

Failure to verify the server's certificate or time-var- 
ying value (illustrated by the NO outputs of elements 33 
and 34) results in an error and termination of the trans- 
action. Symbol 35 is a representation that permits fur- 
ther processing, i.e. the generation of the secret session 
key, when both the received certificate and time-varying 
have been verified (indicated by YES outputs of ele- 
ments 33 and 34). 

Elements 36, 37 and 38 illustrate the functional 
processes performed by the client 20 to generate mes- 
sages 12 and 1 3. Message 12 is generated by concate- 
nating the session key 22 and the time-varying value 
from facility 23 at element 36 and performing a public 
key encryption on the combination in public key opera- 
tion 37 with the public key of server 40 retrieved from 
read and store element 30 or key storage unit 25. Mes- 
sage 13 is generated by performing an encryption at el- 
ement 38 on the certificate 21 with the session key 22. 

The functional elements and blocks of client 20 de- 
fine operational steps performed by a processor, e.g., 
processor 2 of Figure 1. Similarly, the functional ele- 
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ments and blocks of server 40 illustrate operational 
steps performed by the server's processor 60. 

Server 40 of Figure 5 includes a certificate (CERT- 
S) 41 provided by the trusted certification authority, a 
facility for generating time-varying values (TS) 42. the 
private key of the server (PRIVqerv) ^3 and the public 
key of the trusted certification authority (PUBtca) 44. 
Certificate 41 is a certificate for the server's 40 public 
key. and contains a message which includes the serv- 
er's public key and that identifies the server as a valid 
and authorized holder of the public key. Facility 42 may 
be provided by a clock. The key 43 is the server's private 
key of the public key/private key pair used in standard 
public key cryptography. Key 44 is the public key of the 
trusted certification authority. CRL 45 is an optional el- 
ement that stores certificate revocation lists for both 
server's and client's certificates. These lists are signed, 
dated messages received from the trusted certification 
authority. The server CRL is for forwarding to a client 
during the herein described protocol or ancillary to the 
protocol. The client CRL would sen^e, for example, as 
a list of revoked smart cards, i.e., cards that have been 
lost, stolen, destroyed or that have expired. 

The server's certificate and private key, the public 
key of the certification authority and the CRL are stored 
in memories of the server. These memories are ac- 
cessed by a processor of the server in accordance with 
an operating procedure for executing the authentication 
protocol. 

Elements 1 7 and 18 illustrate the functional process 
for generating message 1 1 . The time-varying value from 
facility 42 is signed with the private key 43 of the server 
40 in private key operation 1 7. The signed time-varying 
value is then concatenated with the certificate 41 in the 
concatenate operation 18 to thereby form message 11. 

Blocks and elements 51 through 56 represent func- 
tional processes of the protocol performed by the server 
40. Functional element 51 performs a private key oper- 
ation with the private key 43 on the received message 
1 2. A comparison at 52 provides verification of the time- 
varying value received from the client 20. This may be 
done by comparing a timestamp received with the cur- 
rent timestamp of a clock from facility 42. or by storing 
a time-varying value sent to the client and comparing 
the stored time-varying value with the time-varying val- 
ue returned by the client to see that they are in corre- 
spondence. Gate symbol 53 represents the permissive 
continuation of the processing upon the verification of 
the receipt of a proper time-varying value. Functional 
element 54 performs a decryption of the message 13 
using a key 22 received from the client 20. Functional 
element 55 performs a public key operation on the cer- 
tificate with the public key 44 of the trusted certification 
authority Block 56 provides for the verification of the 
certificate with or without the CRL of clients in a manner 
well understood by those skilled in the art. 

Initially the client 20 may have to gain the trust of 
the server 40 before it will reveal its certificate 21. This 
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protects against revealing the certificate to unauthorized 
third parties who could then use the certificate to imper- 
sonate client 20. Client 20 gains the trust of the server 
40 through a public key protocol. 

Considering the Figure 5 illustration, so that client 
20 may gain its trust, upon a request for access the serv- 
er 40 reveals its certificate 41 by combining the certifi- 
cate 41 with the signed time-varying value from facility 
42 to form message 11 CERT-S{TS}PRIVserv Client 
20 receives the message 11 sent over the communica- 
tions channel 1 5. verifies the signature on the certificate 
with the trusted certification authority's public key 24 in 
public key operation 32 and verification process 33, and 
processes the certificate in operation 30 to read and 
store the public key of the server Client 20 then uses 
the public key of the server in public key operation 31 to 
obtain the time-varying value. As indicated above, the 
public key of server 40 alternatively may be retrieved 
from public key storage unit 25 where used. Checking 
of the time-varying value lo see that it is valid is done in 
comparison unit 34. A failure to verify the server's cer- 
tificate or validate the received time-varying value ter- 
minates the transaction. Signature verification, particu- 
larly for RSA, is computationally inexpensive, so the 
computational burden on the client 20 is minimal. As an 
additional step in certificate verification, the client 20 
may check the values of one or more fields of the cer- 
tificate 41 to determine whether the server 40 is author- 
ized for transactions with the client 20. It is presumed 
that the trusted certification authority of interest issues 
authorized certificates only to trusted servers, so the 
pair of signature verifications is sufficient for the client 
20 to gain trust in the server 40. 

Once client 20 verifies the time-varying value from 
42 and the certificate 41 of server 40, trust of the sen/er 
40 is established. Thereafter, client 20 generates a ran- 
dom secret session key (KSS) at 22, combines this key 
with its time-varying value (TS) generated by a clock at 
23, or where no clock is present replicates the time-var- 
ying value received from the server, to form a message 
and encrypts the message with the public key (PUB. 
SERv) of server 40 obtained from storage at element 30 
or 25 to form the encrypted message 12. Again, for RSA, 
encrypting with the server's public key is computation- 
ally inexpensive so this is not a burden on the client. 

The encrypted message 12, {KSSITS}PUBserv, 's 
sent to the server 40 where it is received and processed 
for recovery of the secret session key KSS by decrypting 
the message 12 with private key 43 in private key oper- 
ation 51 . A checking of the time-varying value TS dem- 
onstrates to the server 40 that a client is active in the 
transaction, not an impersonator replaying a recorded 
message. 

Client 20 then encrypts its certificate 21 using the 
secret session key to produce encrypted message 13, 
{CERT-C}KSS, and sends it to server 40. Messages 12 
and 13 may be combined as one message {KSSITS} 
PI-'Bserv{CERT-C} KSS. Server 40 receives the en- 
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crypted message 1 3 and decrypts it in decryption oper- 
ation 54 to gain the client's 20 certificate 21 . Certificate 
21 is processed in public key operation 55 witfi the trust- 
ed certification authority's public key stored at 44. After 
verification at 56, with or without the optional CRL in unit 
45. the authenticity of client 20 is accepted by server 40 
and the transaction can be undertaken. 

When clocks are used for both tinnestamp facilities, 
the client and the server need to account for variations 
in their clocks when checking that the timestamp re- 
ceived is current. One procedure is to determine the dif- 
ference between the two clock timestamps, for example, 
the client determines the difference between the re- 
ceived timestamp and its own clock generated times- 
tamp, and compares that difference to a pre-set refer- 
ence value to see that it is less than the reference value. 
Other techniques known to those skilled in the art may 
be used to account for the clock variations. See, for ex- 
ample, Weiss. U.S. Patent 4,885,778, entitled "Method 
and Apparatus for Synchronizing Generation of Sepa- 
rate Free Running, Time Dependent Equipment." which 
describes a technique for synchronizing client and serv- 
er clocks in an authorization protocol. 

In place of a timestamp a challenge may be used. 
A challenge may comprise any-time varying message 
that can be processed and verified. 

The client may also store a CRL of servers. Either 
as a part of the authentication protocol or subsequent 
thereto, the server and the client may exchange lists of 
revoked certificates. 

In the embodiment illustrated in Figure 4A, mes- 
sage 1 1 consists of the public key certificate 41 of server 
40. Here, client 20 does not have or need to have prior 
possession of the server's public key. Possession of the 
server's public key is acquired by the client receiving 
and reading the public key certificate 41 . The signature 
on the certificate is verified with the Trusted Certification 
Authority's public key 24 and the certificate is verified by 
conventional verification procedures as discussed in the 
description of Figure 5. This public key of the server is 
then used in public key operation 37. The time-varying 
value is generated locally at facility 23. As seen from 
Figure 4A, client 20 comprises only the elements, e.g., 
24, 32, 33 and 26 to verify the certificate and its signa- 
ture and a functional element 30 to read the received 
certificate 41 and store the public key PUBserv 
server's processing to form message 11 involves only 
the sending of its certificate 41 . The remainder of the 
components, functional elements and operations of fig- 
ure 4A correspond with those in Figure 5. 

In the embodiment of Figure 4B, the message 11 
consists of certificate 41 and a time-varying value TS. 
The time-varying value TS is needed where a client 20 
does not have a facility for generating its own time-var- 
ying value. Thus, as shown, server 40 forms message 
1 1 by concatenating at element 1 8 the certificate 41 with 
the time-varying value from facility 42. In Figure 4B, cli- 
ent 20 verifies via 24, 32 and 33 the signature on the 
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certificate, optionally via 26 the revocation status of the 
certificate and at functional element 39. reads and 
stores the server's public key and the time-varying value 
sent by the server. The time-varying value is processed 
and replicated or modified for use in forming message 
12. This embodiment is advantageous since its imple- 
mentation requires few structural components and com- 
putational operations. The client simply obtains the val- 
ue TS and public key of the server needed for generating 
message 1 2 from the server. The server then processes 
the messages received as in the previously described 
embodiments. When a timestamp is not used by the 
server as the time-varying value, neither the server or 
the client needs a clock. Public key storage element 25 
is optional. 

In Figure4C, message 11 consists of a time -varying 
value TS. As previously described, client 20 may have 
no clock or timestamp facility. It therefore has to receive 
a time-varying value at facility 23 or the tike. Again, the 
received time-varying value may simply be replicated, 
or modified in a predetermined manner, and returned to 
server 40 in message 12. This assures the server that 
a current transaction is taking place. Again, neither party 
needs a clock. However, the client has to have a stored 
copy of the public key of server 40, i.e., an clement 25 
of memory 4 with a stored copy of the public keys of 
various servers with which it will interact. Server 40 only 
requires the message generating elements necessary 
to send a time-varying value. The remaining elements 
depicted in Figure 4C are like those in Figure 5 and op- 
erate in a similar manner. 

The content of the messages generated and sent 
by a client to a server may be as shown in Figure 6. Here 
the time-varying value is concatenated with the certifi- 
cate of the client instead of with the secret session key. 
As shown, client 20 in public key operation 37 encrypts 
the secret session key with the server's public key, the 
server's public key being produced as in any of the pre- 
viously described embodiments, concatenates at 36 the 
time-varying value, obtained as in any of the previously 
described embodiments, with the client's certificate 
(CERT-C), and encrypts at 38 the result using the secret 
session key. The processing in the server is modified to 
accommodate the change in the messages 12 and 13, 
causing the time-varying value verification to be subse- 
quent to the decrypting at 54. The server decrypts mes- 
sage 12 using its private key to recover the session key 
and decrypts the time-varying valueicertificate with the 
secret session key. The certificate is subjected to a pub- 
lic key operation and verifying procedure as in elements 
such as 55 and 56 as shown in the Figure 5 embodi- 
ment. The variation shown in Figure 6 may be practiced 
with any of the embodiments hereinbefore described. 

In some instances a session key in not used, as for 
example where the subsequent communications of the 
overall transaction session are not encrypted. The cli- 
ent's certificate is simply concatenated with a time-var- 
ying value and the result is encrypted with the server's 
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public key to form the message 12 which is sent directly 
to the server. Figure 7 shows, in part, a protocol that 
does not use a session key. The client 20 concatenates 
at 36 a time-varying value produced as in any of the pre- 
viously described embodiments, and encrypts at 37 the 
result with the server's public key obtained as in any of 
the previously described embodiments. Server 40 de- 
crypts the message at 51 with its private key verifies at 
52 the time-varying value, and processes the client's 
certificate as hereinbefore described to authenticate it. ^ 
A smart card using this protocol may only comprise a 
processor, a memory storing the certificate for the card 
and the public key of servers and a facility for providing 
a time-varying value. The smart card may then engage 
in a non -interactive protocol with a server for the pur- i 
pose of establishing its authenticity to a server. In an 
interactive protocol, the server in a communication to 
the client provides a time-varying value and its public 
key certificate as in Figure 4B. and the smart card proc- 
essor processes the receipt of same to produce a time- 2i 
varying value and the public key of the server. The other 
interactive embodiments of Figures 4A and 4C and Fig- 
ure 5 may also be modified to have no session key. 

It is also possible to modify the aforementioned em- 
bodiments to encrypt only part of the certificate, which 2i 
may lead to greater efficiency in the protocol. For in- 
stance, the client can encrypt only the signature on the 
certificate, transmitting the rest of the certificate unen- 
crypted. Since a certificate is not valid without a signa- 
ture, an opponent who obtains only the non-signature 30 
part of the certificate will not be able to impersonate the 
client. 

As a generalization, the client can encrypt any data 
essential to the verification of the certificate. The signa- 
ture is one example; another example is a part of the 3S 
signature, large enough so that the opponent cannot 
guess it. A third example is a secret certificate serial 
number assigned by the certification authority. In gen- 
eral, the most efficient approach, in terms of communi- 
cation requirements, is to encrypt something that is al- 40 
ready required by the server, rather than something 
new. Since the signature is already required, it is a nat- 
ural choice, though other parts of the certificate may be 
appropriate as well. 

In some cases, it may be more efficient in terms of 4S 
communication bandwidth to encrypt more than just the 
data required to verify the certificate. For instance, if the 
encryption is performed with the public key of the server, 
then the client can encrypt as much additional data as 
can be encrypted with a single public^key encryption op- so 
eration. The approach of encrypting the entire certificate 
is an extreme example. As anotlier variation, it is pos- 
sible to encrypt part of the certificate with a public-key 
encryption, and part with a secret-key encryption. 

Figure 8 illustrates in part a variation of the embod- 55 
iment of Figure 5 wherein only a portion of the certificate 
21 is encrypted and transmitted to the server 40 with the 
remainder of the certificate (REST-C) being transmitted 



in unencrypted form. Thus, the certificate 21 can be split 
at 81 so that any data in the certificate which is essential 
to the verification of the certificate is split and subse- 
quently encrypted by secret session key (KSS) at 38. 
s The remainder of the certificate (REST-C) is transmitted 
unencrypted to the server 40. 

Upon receipt of the transmitted encrypted and non- 
encrypted portions of the certificate the server 40 de- 
crypts the former at 54 and joins the latter at element 82 
so as to obtain the client's certificate 21 . Thereafter as 
illustrated in Figure 5, the certificate is processed in pub- 
lic key operation 55 with subsequent verification at 56. 
As previously noted, the encrypted portion (X-C) of the 
client's certificate may be any portion which is sensitive 
5 or essential to the verification of the certificate such as 
the signature or a portion of the signature. 

Figure 9 is an illustration of a variation of the em- 
bodiment of Figure 6 wherein only a portion (X-C) of the 
client's certificate 21 is encrypted with the remainder 
0 (REST-C) being transmitted in unencrypted form. In this 
regard the certificate 21 is again split at 81 to obtain an 
essential portion (X-C) of the certificate. Thereafter, as 
may be seen from Figures 9 and 6, the essential portion 
of the certificate is concatenated al 36, encrypted at 38 
> and transmitted to the server 40. Moreover the unen- 
crypted portion (REST-C) of the certificate 21 is trans- 
mitted to the server 40 for joining at 82 with the decrypt- 
ed portion (X-C) for subsequent verification of the cli- 
ent's certificate 21. 
' Figure 10 illustrates a variation of Figure 7 wherein 
only an essential portion of the client's certificate 21 is 
encrypted with the remainder of the certificate being 
transmitted unencrypted. More specifically the certifi- 
cate 21 is split at 81 to form an essential portion (X-C) 
which is concatenated and encrypted at 36 and 37, re- 
spectively, for transmission to the server 40. Meanwhile, 
the rest of the certificate (REST-C) is transmitted to the 
server in unencrypted form for joining at 82 with the es- 
sential portion of the certificate as decrypted at 51 and 
52 to thus provide the server with the client's certificate. 

Another approach applies when the certificate con- 
tains a field that is computed as the one-way function, 
such as a cryptographic hash function, of a secret value. 
In this case, the secret value is encrypted and transmit- 
ted to the server, and the server computes and com- 
pares the one way function of the received secret value 
to the field in the certificate, after verifying the certificate. 
This has the advantage that the secret value can be con- 
cealed from the certification authority during the process 
of obtaining a certificate, so that the certification author- 
ity cannot later impersonate the client. The approach of 
encrypting a secret data value whose one-way function 
value is contained in the certificate has this property A 
related approach is described in the Secure Electronic 
Transaction Specification (MasterCard and Visa, June 
24, 1996). In SET. the name field in a certificate is 
formed as a one-way hash of the account number and 
other information, and during a purchase protocol, the 
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account number and the other information are encrypt- 
ed and transmitted to a server, which compares their 
hash to the name field of the certificate. However, au- 
thentication in SET is also based on digital signatures, 
as in other conventional approaches. The account 
number itself is concealed for the protection of the ac- 
count owner, not primarily for authentication, and it is 
not concealed from the certification authority. 

Related to this, there could be a hash-tree of secret 
values whose root is included in the certificate, where a 
path through the tree is encrypted and transmitted to the 
server. The hash-tree variation provides greater protec- 
tion against misuse by the server, since different paths 
could be associated with different servers. Here it is im- 
portant to note that the path is encrypted. However, in 
a different approach based on a hash tree, the root is 
included in the certificate and a digital signature, which 
need not be encrypted, is formed with the tree. See, for 
example, Merkle. U.S. Patent 4,309,569, entitled "Meth- 
od of Providing Digital Signatures." In this regard, the 
storage requirement for the latter approach is quite large 
and may be impractical in a smart card or similar proc- 
essor. 

Regarding hash trees, as may be seen in Figure 11 . 
a hash tree consists of a root and one or more children, 
where if there is more than one child, each child must 
be a hash tree, and if there is only one child, the child 
is a leaf. A leaf has no children. A hash tree thus consists 
of many leaves, connected to the root through interme- 
diate nodes. Each leaf has a predetermined value. The 
value of a hash tree is the hash of the values of Its chil- 
dren and the value of a hash tree is thus computed re- 
cursively. 

A path through a hash tree consists of a leaf and 
the values of the siblings of its successive parents. A 
path is verified by recalculating the value of the root 
based on the values in the path. This can be done re- 
cursively, since the value of each child of the root is ei- 
ther in the path, or can be recalculated from the rest of 
the path. As may be seen in Figure 11 , the path from X3: 
^3. h(X4). h(h(Xi ), h(X2)) can be verified by recalculating 
the root given the values of siblings in the path. 

Only one leaf is contained in a path, and provided 
that the hash function is one-way, the values of leaves 
not in a given path cannot be determined from the path. 
Thus, it is possible to reveal paths for each leaf in the 
tree such that a different path is used for each verifier, 
so as to prevent misuse. Only the root needs to be trust- 
ed initially by a verifier. It should be noted that the pre- 
viously mentioned approach of storing the hash of a se- 
cret value in the certificate is really just a special case 
of a hash tree, where there is only one leaf. 

In the above described protocols, the server 40 can 
easily recover the certificate sent by client 20 but no third 
party can because only client 20 and server 40 know the 
secret session key and/or only the server knows its pri- 
vate key. The server 40 is convinced that the client 20 
is authentic and active in the transaction. Client 20 is 
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assured that its certificate is seen only by server 40. 
While server 40 has enough information after a trans- 
action to impersonate client 20, server 40 is of such in- 
tegrity as to be trusted not to reveal the client's certificate 
to any third party or to impersonate client 20. 

Trust of server 40 is a realistic consideration since 
servers are currently trusted to not reveal passwords or 
otherdata belonging to a client. In financial applications, 
the server (card reader) is trusted not to reveal account 
numbers or a personal identification number (PIN). 
Thus, it is reasonable to assume that the server or card 
reader will not reveal certificates. 

In the case of RSA, the encryption and signature 
operations can follow the techniques described in PKCS 
#1 : RSA ENCRYPTION STANDARD (RSA Laborato- 
ries, November 1993), in I nternationai Standard 9796: 
Information Technology, Security Techniques: Digital 
Signature Scheme Giving Message Recovery (ISO/ 
lEC, 1991), in M. Bel/are and R Rogaway "Optimal 
Asymmetric Encryption" in Advances in Crypiology -Eu- 
rocrypt '94, pp 92-111 (Springer-Veriag (New York 
1995)) or in similar standards, as are well known to 
those familiar with RSA. 

The client and server certificates may be signed by 
the same trusted certification authority or different trust- 
ed certification authorities. The client and server, in ei- 
ther case, needs to have in its possession, the public 
key of the trusted certification authority that signed the 
received certificate in order to verify it. 

In the above noted embodiments where the server's 
public key is provided to the client, the same server pub- 
lic key was used for encryption and verification. Howev- 
er, the public key of the server 40 for encryption may be 
different than the public key for verifying signatures. In 
Figure 5, for example, elements 31 and 37 could employ 
different public keys by storing two different public keys 
associated with the same server; one of which would be 
for verifying the server signatures at 31 and the other 
for encrypting data at 37 to be sent to the server Alter- 
natively, the certificate of the server could contain two 
separate keys along with identification as to their pur- 
poses. Moreover, in either alternative, element 43 of Fig- 
ure 5, for example, would provide appropriately different 
private keys to elements 1 7 and 51 . 

As an additional modification to the disclosed ex- 
emplary embodiments, the client's certificate (CERT-C) 
may be generated once by the certification authority and 
stored in the client's memory 21 or it may be a certificate 
generated by a certification authority whenever the cli- 
ent is authenticated to the certification authority, e.g. as 
part of a daily log-in procedure, fvloreover, the authenti- 
cation operation could be carried out by techniques de- 
scribed herein or by other authentication techniques. 
The new certificate could also contain the time at which 
authentication occurred and could expire later at some 
set time. Thus, the exposure time of the certificate would 
be limited if Jt is obtained by an opponent. The new cer- 
tificate could also specify the types of operations for 
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which the client is currently authenticated. Under such 
circumstances, the client would present the new certifi- 
cate to the server to authenticate itself to the server, and 
the server would check that the certificate has not ex- 
pired and that the client is authorized for a particular type 
of operation. 

In financial applications, a certificate can be easily 
authenticated since it carries the digital signature of a 
certification authority. An account number cannot be 
easily authenticated because checking is done through i 
accessing an on-line database. Therefore, in a financial 
application the certificate has clear benefits over an ac- 
count number or an account number in combination with 
a PIN verification procedure. 

In addition, if the account number contains check 
digits, they can usually be constructed by any third party 
with a public algorithm. Thus a third party can easily 
forge account numbers. For this reason, a database 
check is essential. Moreover, if the check digits are com- 
puted based on a secret key stored in the server, the 2( 
same secret key must be stored in all servers. There- 
fore, an opponent who compromises one server can 
forge account numbers. This is another reason for the 
practice of having a central database perform the check. 
With certificates, the server stores only the trusted cor- 2£ 
tiftcation authority's public key, not the private key. Thus 
an opponent that compromises a server may obtain ac- 
cess to certificates known to that server, but does not 
gain the ability to form new ones. 

As previously noted, the system as illustrated in Fig- 30 
ure 1 2 is more fundamental and has a more general pro- 
tocol whereby a user is enabled to confidentially deliver 
a credential authorizing the user to perform an opera- 
tion. In order to reflect the more fundamental system and 
protocol the terms "user", "credential" and "verifier" are 35 
used rather than "client", "certificate" and "server", re- 
spectively, so as to indicate the more general nature of 
the Figure 12 exemplary embodiment. In Figure 12 the 
credential includes information essential to verify the 
credential which is transmitted to a verifier by way of an 40 
encrypted communications channel. In the illustrated 
system the user 60 may be an individual, a computer or 
some other entity. Moreover, the credential can be 
stored on a smart card or other device held by the user 
or may be held on the user's computer. Furthermore, 4S 
the encrypted communications channel 65 can be be- 
tween the user's smart card and the verifier or the user's 
computer and the verifier. Additionally, the verifier can 
be a client, a server or some other entity on a computer 
network having a secure channel connected to the user 
whereby at least data essential for verifying the user's 
credential is transmitted to the verifier. 

Although the credential held by the user would in- 
clude a digital signature by a credential issuing authority, 
it is only necessary for the system illustrated in Figure 55 
12 to transmit some portion of the credential which 
would be necessary for verification of the credential to 
be transmitted to the verifier via the encrypted channel. 



That is to say, although the entire credential could be 
provided to the verifier via the encrypted channel, en- 
cryption could be limited to only portions essential for 
verification such as the digital signature on the creden- 
tial, encryption of a secret value whose one way function 
value is stored in the credential or encryption of a path 
through a hash tree whose root is stored in the creden- 
tial. Thus, element 62 would select all of the data of cre- 
dential 61 or at least an essential portion thereof for 
' transmission via the encrypted communication channel 
66 for verification at 71 as illustrated in Figure 12. Other 
non-selected data would be transmitted through a non- 
encrypted channel and input to the verification step in a 
manner similar to that which is illustrated in Figures 8 
through 10, for example. 

Stated differently, with regard to the embodiment of 
Figure 12. although it is possible for all data of the cre- 
dential to be transmitted through an encrypted channel, 
the primary focus of Figure 12 is that only data essential 
for verification need be transmitted through the encrypt- 
ed channel. Additionally, it is important to note that the 
operation as illustrated in Figure 12 does not depend on 
operations with keys belonging to the user such as a 
digital signature by the user. Such keys, however can 
bo included in the credential, but verification operations 
do not depend thereon. 

The credential can be verified by verifying the digital 
signature with the public key of the credential Issuing 
authority and/or by performing other operations previ- 
ously disclosed such as comparing the computed one 
way function of a transmitted secret value to the com- 
puted one way function of the secret value included in 
the credential or by checking the path through a hash 
tree. 

With regard to the encrypted communications chan- 
nel, the channel may comprise encryption with a secret 
key which is shared by both the user and the verifier, by 
the user's computerand the verifier or by encryption with 
the verifier's public key in a manner similar to that illus- 
trated in the embodiment of Figure 7. Where a shared 
secret key is used, the secret key may be established 
by any of a number of techniques including the use of a 
third party key server, the user or the user's computer 
generating a random secret key and encrypting it with 
the verifier's public key and sending it to the verifier as 
in previously disclosed embodiments. Moreover, a time 
stamp or other non-repeating values may be included 
in the process of establishing the key as in previous em- 
bodiments or by encrypting the data necessary to verify 
the credential or both. Additionally, In the event that en- 
cryption on channel 66 uses the verifier's public key, as 
in previously disclosed embodiments, a certificate for 
the verifier's public key may be verified first by the user 
or its computer 

As in the previously disclosed embodiments, the 
verifier of Figure 12 is trusted not to reveal or misuse 
the user's credential. Moreover, since the data neces- 
sary to verify the credential is encrypted, the user is pro- 
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tected from opponents who cannot connpromise the ver- 
ifier's security. Moreover, since the credential includes 
a digital signature, the system is protected from oppo- 
nents who can compromise the verifier's security since 
they can only reuse existing credentials and cannot gen- 
erate new ones. In this regard, as noted with the previ- 
ously disclosed embodiments, the user's credential can 
be obtained as a one-time value resulting from a suc- 
cessful log-in operation or can be obtained at some oth- 
er interval. That is to say, the credential may authorize 
the userto perform certain operations and can also have 
further restrictions, such as limited time periods or limi- 
tations as to a list of authorized verifiers or servers. 

In any event, the system as illustrated in Figure 12, 
for example, provides the fundamental features of al- 
lowing a user to confidentially deliver to a verifier infor- 
mation which is essential for verifying a credential as- 
signed by a certification authority which authorizes the 
user to conduct some transaction wherein the credential 
may or may not involve the use of a one way function 
but always contains the digital signature of the creden- 
tial issuer 

Moreover, although the system illustrated in Figure 
12 merely illustrates the functional elements and blocks 
of a more fundamental system involving confidential de- 
livery to a verifier of information essential for verifying 
whether a user is authorized to perform an operation, 
various features of the previously disclosed embodi- 
ments may also be included in the Figure 12 embodi- 
ment- For example, as previously noted, encryption on 
the encrypted communication channel 66 may be ob- 
tained with a shared secret key pre-installed with the 
user and verifier or established by encryption with the 
verifier's public key. Alternatively, other well known tech- 
niques for establishing a secret key by agreement can 
be used such as through the use of a Diffie-Hellman al- 
gorithm. Additionally, encryption as in the embodiments 
of Figures 4A through 7 may be obtained through the 
use of the verifier's public key or the use of a non-re- 
peating value such as a time stamp. Moreover, as afore- 
mentioned, the entire credential may be encrypted or 
only essential data of the credential may be encrypted 
with the remainder of the credential being transmitted 
unencrypted in the manners illustrated in Figures 8 
through 10, for example. 

While the invention has been described in connec- 
tion with what is presently considered to be the most 
practical and preferred embodiment, it is to be under- 
stood that the invention is not to be limited to the dis- 
closed embodiment, but on the contrary, is intended to 
cover various modifications and equivalent arrange- 
ments included within the spirit and scope of the ap- 
pended claims. 
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in a client-server electronic transaction where a 
server having a public key/private key pair and a 
certification authority's public key and a client hav- 
ing a certificate signed by the certification authority 
are coupled by a communications channel compris- 
ing, 

the client, 

a) generating a secret session key, 

b) producing a time-varying value, 

c) concatenating one of the secret session key 
or the certificate with the time-varying value, 

d) encrypting the secret session key or the se- 
cret session key concatenated with said time- 
varying value with the server's public key to pro- 
duce a first message, 

e) encrypting at least a part of the certificate or 
the certificate concatenated with the time-var- 
ying value with said secret session key to pro- 
duce a second message, and 

f) sending the first and second messages to the 
server, where a decrypting operation by the 
server on the first message with the private key 
of the public key/private key pair provides the 
server with the secret session key, a decrypting 
operation on the second message with the se- 
cret session key provides the server with at 
least a part of the client's certificate, the de- 
crypting operation with one of the keys provides 
the time-varying value, and a verifying opera- 
tion on the time-varying value and a public key 
operation with the certification authority's public 
key and verifying operation on the client's cer- 
tificate establish the authenticity of the client. 

A method as in claim 1 wherein the client's certifi- 
cate comprises structural information about the cli- 
ent but no public key 

A method as in claim 2 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time 
varying-value that is concatenated with the secret 
session key or the certificate. 

A method as in claim 1 further including the server 
sending a time-varying value to the client, said client 
using the received lime-varying value for the time- 
varying value that is concatenated with the secret 
session key or the certificate. 

A method as in claim 1 wherein establishing the au- 
thenticity of the client is non-interactive. 



Claims 

1 . A method for establishing the authenticity of a client 



55 6. A method as in claim 2 wherein establishing the au- 
-thenticity of the client is non -interactive. 

7. A method as in claim 1 wherein the certificate in- 
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eludes a first data portion which is essential for ver- 
ification of the certificate and a second data portion, 
said method prior to executing step e) splitting said 
first data portion from said second data portion, 
sending said second data portion to the server with- 
out encryption, encrypting and decrypting the sec- 
ond nnessage in steps e) and f), respectively, only 
said first data portion, of the certificate, joining said 
first and second data portions at the server and 
thereafter performing the verifying operation of step 
f). 

8. A method as in claim 1 , wherein the certificate in- 
cludes data essential for verification of the certifi- 
cate as well as non-essential data and only the es- 
sential data is encrypted and decrypted respective- 
ly in steps e) and f). 

9. A method as In claim 4, wherein the certificate in- 
cludes data essential for verification of the certifi- 
cate as well as non-essential data and only the es- 
sential data is encrypted and decrypted respective- 
ly in steps e) and f). 

1 0. A method for establishing the authenticity of a client 
in a client-server electronic transaction where a 
server and a client are coupled by a communica- 
tions channel, comprising, 

establishing a client's trust in the server over 
the communications channel, 
the client having stored in a memory a certifi- 
cate and the server's public key, and 

(a) generating in a processor, upon having 
established the trust in the server, a secret 
session key. encrypting the secret session 
key with the server's public key and send- 
ing the encrypted secret session key as a 
message to the server over the communi- 
cations channel, and 

(b) encrypting at least a part of said certif- 
icate with said secret session key and 
sending the results of the encryption to the 
server over the communications channel, 



whereby decryption with the server's private 
key associated with the server's public key by 
the server yields the secret session key and de- 
cryption of the results by the server with the se- 
cret session key produces at least a part of the 
client's certificate which is proof of the client's 
authenticity. 
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12. A method as in claim 11 wherein said server has a 
public key certificate for its public key and steps in 
the method include sending said public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and to recover and store 
the server's public key and using the recovered pub- 
lic key or a different public key of the server in the 
step of encrypting the secret session key or the se- 
cret session key concatenated with a time-varying 
value. 

1 3. A method as in claim 1 2 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with the secret 
session key. 
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11. A method as in claim 10 where said certificate for 
the client includes structured information about the 
client but no public key 



ss 



14. A method as in claim 10 wherein said server has a 
public key certificate for its public key and steps in 
the method include sending the public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and to recover the server's 
public key and using the recovered public key or a 
different public key of the server in encrypting the 
secret session key or the secret session key con- 
catenated with a time- varying value. 

15. A method as in claim 1 4 further including the server 
sending a time-varying value to the client, said client 
using the received trme-varying value for the time 
varying value that is concatenated with the secret 
session key. 

16. A method as in claim 14. wherein the client's certif- 
icate includes data essential for verification of the 
client's certificate as well as non-essential data and 
only the essential data is enciypted and decrypted. 

17. A method as in claim 1 0 wherein the step of estab- 
lishing a client's trust in the server includes the client 
performing a public key operation with a stored cer- 
tification authority's public key for the verifying of a 
certificate received from the server, processing the 
certificate received from the server to recover the 
public key of the server, storing the public key of the 
server in said memory and performing a public key 
operation with the server's public key for recovering 
an encrypted lime-varying value received from the 
server. 

18. A method as in claim 17 including generating a time- 
varying value and concatenating that time-varying 
value with the secret session key prior to the step 
of encrypting with the server's public key or with the 
certificate prior to the step of encrypting with the se- 
cret session key. 

19. A method as in claim 18 wherein said server has 
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stored in memory its private key corresponding to 
said server's public key and the trusted certification 
authority's public key. and has a facility for generat- 
ing a time-varying value, 28. 

said server receiving said nnessage and in a s 
processor decrypting said message with said pri- 
vate key to recover said secret session key, using 
said secret session key in a decrypting operation to 
recover the at least a part of the client's certificate 
sent by the client, one of the decrypting operations io 
providing the client's time-varying value, checking 
the client's time-varying value by comparing it with 
a time-varying value from the facility and verifying 
the client's certificate in a public key operation using 
the trusted certification authority's public key 75 

20. A method as in claim 1 9 wherein said server further 
includes stored In memory a certificate revocation 
list and the step of verifying the client's certificate 
includes checking the certificate revocation list. 

21. A method as in claim 20 wherein the client has 
stored in memory a certificate revocation list and in- 
cludes exchanging certificate revocation lists be- 
tween the server and the client. 25 



sential data is encrypted and decrypted respective- 
ly by the client and server. 

A smart card comprising a processor, a read only 
memory and an input/output port. 



22. A method as in claim 18 including combining steps 
(a) and (b) to provide a message, and sending the 
message over the communications channel in one 
sending operation. 30 

23. A method as in claim 18 including using a clock for 
generating the time-varying value in the form of a 
timestamp. 

35 

24. A method as in claim 18 including generating the 
time-varying value by using the time-varying value 
received from the server 

25. A method as in claim 10 wherein the generating of 4o 
a secret session key includes the step of using a 
random number generated from a random number 
generator 

26. A method as in claim 10 wherein the certificate in- 
eludes a first data portion which is essential for ver- 
ification of the certificate and a second data portion, 
said method prior to executing step a) splitting said 
first data portion from said second data portion, 
sending said second data portion to the server with- 
out encryption, encrypting in step a) and decrypting 
at the server only said first data portion, and joining 
said first and second data portions at the server af- 
ter decrypting said results. 



said processor including 

means for producing a trusted server's 
public key, and 

means for executing a protocol stored in 
said memory for establishing the authen- 
ticity of the smart card to a trusted server 
and for generating a secret session key, 

said read only memory having stored therein a 
certificate for the smart card, 
said protocol including encrypting the secret 
session key with the trusted server's public key 
and sending the encrypted secret session key 
to the trusted server over the input/output port, 
said protocol further including encrypting at 
least a part of said certificate for the smart card 
with said secret session key and sending the 
encrypted certificate to the trusted server over 
the input/output port. 

29. A smart card as in claim 28 wherein said read only 
memory has stored therein a plurality of public keys 
belonging to respectively different servers which 
may be used as a source from which the trusted 
sewers' public key is produced. 

30. A smart card as in claim 28 further comprising a fa- 
cility for providing a time-varying value and means 
for concatenating the time-varying value with the 
secret session key or the certificate. 



55 



27. A method as in claim 10 wherein the certificate in- 
cludes data essential for verification of the certifi- 
cate as well as non-essential data and only the es- 



31. A smart card as in claim 30 wherein said facility for 
providing a time-varying value comprises a clock. 

32. A smart card as in claim 30 wherein said facility for 
providing a time-varying value comprises means for 
storing a received time-varying value from a server 
and for supplying it or a modification thereof as the 
time-varying value of the smart card. 

33. A smart card as in claim 30 wherein said processor 
further comprises means for establishing trust in a 
server said means including using a public key op- 
eration with a certification authority's public key for 
establishing the identity of a server and a timestamp 
of the facility for providing a time-varying value for 
establishing that a message received from a server 
comprising a timestamp is current. 

34. A smart card as in claim 28 wherein said certificate 
for the smart card includes structured information 
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about the smart card but no public key. 

35. A smart card as in claim 28 wherein said means for 
producing a trusted server's public key includes 
processing a public key certificate received from a s 
server. 

36. A smart card as in claim 34 further comprising a 
timestamp facility providing timestamps for verify- 
ing received timestamps and supplying a timestamp io 
to messages generated by the smart card. 

37. A smart card as in claim 28 further comprising 

a timestamp facility, is 
a number generator, 
said protocol including, 

establishing a server as a trusted server by a 
public key operation using the public key of the 
server to verify any message received from a 
server over the input/output port, using the 
timestamp to verify a timestamp received from 
the server and the public key of the trusted cer- 
tification authority to verify a certificate provid- 
ed by the server, and after the verifications, 
generating the secret session key using a 
number supplied by the number generator, 
concatenating a timestamp provided by said 
timestamp facility with the secret session key 
and encrypting with the public key used for ver- 30 
ification or with a different public key of said 
trusted server the concatenated timestamp and 
secret session key, and 

sending the encrypted result to the trusted serv- 
er over the input/output port. 3S 



38. A smart card as in claim 28 wherein the certificate 
includes a first data portion which is essential for 
verification of the certificate and a second data por- 
tion and said protocol includes splitting said first and 
second data portions, encrypting only said first data 
portion, and sending the encrypted first data portion 
and an unencrypted second data portion to the 
server 

39. A server having a protocol for Interactively engaging 
with and verifying the authenticity of a client of lim- 
ited computational capacity comprising, 



40 



45 



SO 



a memory storing a private key of the private 
key/public key pair of the server and a trusted 
certification authority's public key, 
a facility for generating time-varying values, 
a processor for performing the protocol, 
said protocol including, ss 

receiving and processing fronn said client a 
message including a session key encrypt- 



ed with the server's public key and at least 
a part of the client's certificate encrypted 
with the session key. one of said session 
key and said at least a part of the client's 
certificate being concatenated with a time- 
varying value, said processing including 
performing a private key operation on the 
message with the server's private key to re- 
cover the session key, decrypting the mes- 
sage with the session key to recover at 
least part of the client's certificate, receiv- 
ing the time-varying value from the mes- 
sage and checking it with the current time- 
varying value of the facility to see that the 
client's time-varying value is proper, per- 
forming a public key operation on the at 
least part of the client's certificate with the 
trusted certification authority's public key 
and verifying the client's certificate. 

40. A server as in claim 39 further including in a CRL 
memory a certificate revocation list and wherein the 
step of verifying the client's certificate includes 
checking the certificate revocation list for the pres- 
ence of the client's certificate. 

41. A server as in claim 40 wherein the protocol further 
includes a step of exchanging certificate revocation 
lists with the client. 

42. A server as in claim 39 wherein said memory stores 
a certificate for the server's public key, and said 
server providing toa client, a time-varying value, the 
server's public key certificate or both. 

43. A server as in claim 39 wherein the message from 
the client includes a first data portion of the client's 
certificate encrypted with the session key and a sec- 
ond data portion of the client's certificate which is 
not encrypted, said protocol including decrypting 
the first data portion of the client's certificate and 
joining the decrypted first data portion with the sec- 
ond data portion. 

44. A smart card comprising a processor, a read only 
memory, an input/output port, and a facility for pro- 
ducing a time-varying value, 

said processor including means for producing 
a server's public key and means for executing 
a protocol stored in said memory for establish- 
ing the authenticity of the smart card to a trust- 
ed server, 

said memory having stored therein a certificate 
for the smart card, 
— said protocol including concatenating at least a 
part of the certificate with a time-varying value 
provided by said facility, encrypting the result of 
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the concatenating with the server's public key 
to form a message and sending the message 
via the input/output port. 

45. A smart card as in claim 44 wherein said facility for 5 
providing a time-varying value comprises a clock. 

46. A smart card as in claim 44 wherein the means for 
producing a server's public key includes receiving, 
processing and verifying a public key certificate of io 
the server provided at the input/output port during 

a transaction. 



ing the certification authority's public key and 
verifies it. establishing the authenticity of the cli- 
ent. 

53. A method as in claim 52 wherein the certificate in- 
cludes a first data portion and a second data portion 
and only the first data portion is concatenated and 
encrypted and the message sent to the server in- 
cludes an encrypted first data portion and an unen- 
crypted second data portion, said server decrypting 
the first data portion and joining the decrypted first 
data portion and the second data portion. 



47. A smart card as in claim 46 wherein the server's 54. A method as in claim 53 wherein the first data por- 

public key used for verifying and encrypting are dif- is tion of the certificate comprises at least a portion of 
ferent public keys of the server a digital signature on the certificate. 



48. A smart card as In claim 44 wherein said facility for 
providing a time-varying value comprises means for 
receiving a time-varying value via the input/output 
port and for supplying it or a modification thereof as 
the time varying value of the smart card. 

49. A smart card as in claim 48 wherein the means for 
producing a server's public key includes receiving 
and processing and verifying a public key certificate 
received from a server at the input/output port. 

50. A smart card as in claim 44 wherein said certificate 
for the smart card includes structured information 
about the smart card but no public key 

51. A smart card as in claim 44 wherein the certificate 
includes a first data portion and a second data por- 
tion and said protocol concatenates and encrypts 
only the first data portion and the message sent via 
the input/output port includes an encrypted first data 
portion and an unencrypted second portion. 

52. A method for establishing the authenticity of a client 
in a client-server electronic transaction where a 
server having public key/private key pairs and a cer- 
tification authority's public key and a client having a 
certificate signed by the certification authority are 
coupled by a communications channel comprising 

the client, 

producing a time-varying value, concatenating 
the time-varying value with at least part of said 
certificate, encrypting the concatenated result 
with the server's public key to produce a mes- 
sage, and sending the message to the server, 
the server, 

decrypting the message using the private key 
of the public key/private key pair recovers the 
time-varying value and at least part of the cli- 
ent's certificate, verifies the time-varying value 
and processes at least part of the certificate us- 



55. A method as in claim 52 wherein the client's certif- 
icate comprises structural information about the cli- 

^0 enl but no public key. 

56. A method as in claim 55 wherein said server has a 
public key certificate for its public key and steps in 
the method include sending said public key certifi- 
es cate to the client, said client processing the public 

key certificate to verify it and to recover the server's 
public key and using the public key in the step of 
encrypting the concatenated result. 

30 57. A method as in claim 56 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with at least part 
of the certificate. 

35 

58. A method as in claim 55 further including said server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
varying value that is concatenated with at least part 

40 of the certificate. 

59. A method as in claim 52 wherein said server has a 
public key certificate for its public key and steps in 
the method include sending the public key certifi- 
es cate to the client, said client processing the public 

key certificate to verify it and to recover the server's 
public key and using the recovered public key in en- 
crypting at least part of the certificate concatenated 
with a time-varying value. 

so 

60. A method as in claim 59 further including the server 
sending a time-varying value to the client, said client 
using the received time-varying value in the step of 
producing a time-varying value. 

55 

61 . A method as in claim 52 further including the server 
sending a time-varying value to the client, said client 
using the received time-varying value for the time- 
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varying value that is concatenated with at least part 
of the certificate. 

62. A method as in claim 52 wherein establishing the 
authenticity of the client is non-interactive. s 

63. A method as in claim 55 wherein establishing the 
authenticity of the client is non-interactive. 

64. A method as in claim 52 wherein said server has a to 
public key certificate for its public key and steps of 
the method include sending said public key certifi- 
cate to the client, said client processing the public 
key certificate to verify it and wherein the client and 
server use a second public key/private key pair to is 
encrypt/decrypt, respectively, the message. 

65. A method tor determining at a verifier whether a us- 
er is authorized to perform an operation, said meth- 
od comprising the step of obtaining from said user 20 
a credential authorizing said user to perform said 
operation, wherein 

said credential includes a digital signature by a 
credential issuing authority; 26 
at least data essential to verify said credential 
is transmitted from said user to said verifier 
through an encrypted communications chan- 
nel; and 

wherein the determination of authorization 30 
does not depend on an operation with a public 
key belonging to said user. 



66. A method as in claim 65. wherein the credential in- 
cludes data essential for verification of the creden- 3S 
tial as well as non-essential data and only the es- 
sential data is encrypted and the non-essential data 

is sent to the verifier unencrypted. 

67. A method as in claim 66 wherein the credential in- 40 
eludes a field computed as a one-way function of a 
secret value, the secret value is encrypted and sent 

to the verifier and the verifier computes and com- 
pares the one way function of the secret value to 
the field. 



71 . A method as in claim 65 wherein the communicat ion 
channel is encrypted with a key established by en- 
cryption with the verifier's public key. 

72. A method as in claim 71 wherein the verifier's cer- 
tificate is provided to the user and the user verifies 
the certificate. 

73. A method as in claim 71 wherein the key is estab- 
lished by encryption with the verifier's public key 
and a non-repeating value is included with the data 
essential for verification. 

74. A method as in claim 65 wherein the communication 
channel is encrypted with the verifier's public key 
and a non-repeating value is included with the data 
essential for verification. 

75. A method as in claim 65 wherein the verifier's cer- 
tificate is provided to the user and the user verifies 
the certificate. 

76. A method as in claim 65 wherein the entire creden- 
tial is transmitted to the verifier through the encrypt- 
ed communications channel. 

77. A method as in claim 65 wherein the data essential 
to verify the credential includes at least the digital 
signature. 

78. A method as in claim 65 wherein the data essential 
to verify the credential includes at least a secret val- 
ue whose one-way function value is contained in the 
credential. 

79. A method as in claim 65 wherein the data essential 
to verify the credential includes at least a path 
through a hash tree whose root is contained in the 
credential. 

80. A method as in claim 77 wherein the verifier checks 
the digital signature using the credential issuing au- 
thority's public key. 



68. A method as in claim 66 wherein the credential in- 
cludes a root of a hash tree and a path through the 
hash tree is encrypted and sent to the verifier. 

69. A method as in claim 65 wherein the communication 
channel is encrypted with a secret key shared by 
the user and the verifier. 



^5 81. A method as in claim 78 wherein the verifier com- 
putes and compares the one-way function of the se- 
cret value with the one-way function value of the 
credential. 

so 82. A method as in claim 79 wherein the verifier checks 
the path through the hash tree using the root con- 
tained in the credential. 



70. A method as in claim 65 wherein the communication ss 
channel is encrypted with a key established by us- 
ing a key agreement technique: 



83. A method as in claim 66 wherein the verifier checks 
the credential using the credential issuing authori- 
ty's public key. 

84. A method as in claim 65 wherein the credential is 
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issued as a result of successful authentication to the 
credential issuing authority. 

85. A method as in claim 65 wherein the credential is- 
suing authority is the verifier 

86. A method as in claim 84 wherein the credential is- 
sued includes a field computed as a one-way func- 
tion of a secret value, the secret value is not re- 
vealed to the credential issuing authority and the se- 
cret value is transmitted as essential data. 

87. A method as in claim 84 wherein the credential is- 
sued includes a root of a hash tree and a path 
through the hash tree is transmitted as essential da- 
ta through the encrypted communication channel 
and wherein one or more leaves of the hash tree 
are not revealed to the credential issuing authority. 

88. A method as in claim 84 wherein the determination 20 
of authorization includes a determination that the 
credential is not included in a credential revocation 

list. 

89. A method as in claim 65 wherein the credential in- 2B 
eludes data specifying the types of operations for 
which the user is authorized, or the time at which 

the credential expires or a list of authorized verifiers. 

90. A method as in claim 65 wherein the credential in- 30 
eludes the user's public key but the user's public key 

is not used in the determination of authorization. 



muntcation channel is encrypted with a secret key 
shared with the verifier or with the verifier's public 
key and a non-repeating value. 

93. A system as in claim 91 further including a non-en- 
crypted channel for transmitting between the user 
element and the verifier data which is non-essential 
data for verifying the credential. 



70 94. 
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91. A system for determining whether a user is author- 
ized to perform an operation with a verifier, said sys- 
tem comprising: 

a user element for providing all or at least a part 
of the data included in a credential, said user 
element also providing data essential to verify 
the credential, said credential including at least 
a digital signature by a credential issuing au- 
thority; 

said user element having a protocol for engag- 
ing with the verifier and including a device 
which selects data tor transmission to the ver- 
ifier, said data selected by the device including 
at least data essential to verify the credential; 
an encrypted communication channel respon- 
sive to the device for transmitting data between 
the user element and the verifier, and 
the verifier including a protocol for determining 
whether the user is authorized to perform an 
operation wherein the determination does not 
depend on the transmission of a user's public 
key from the user element. 

92. A system as in claim 91 wherein the encrypted com- 



A system as in claim 93 wherein the credential in- 
cludes a field computed as a one-way function of a 
secret value and the secret value is selected, en- 
crypted and sent to the verifier as essential data and 
the protocol of the verifier causes the verifier to 
compute and compare the one way function of the 
secret value to the field. 

A system as in claim 93 wherein the credential in- 
cludes a root of a hash tree and a path through the 
hash Iree is selected as essential data and trans- 
mitted to the verifier. 



96. A system as in claim 93 wherein the data essential 
to verify the credential is the entire credential or the 
digital signature on the credential or a secret value 
whose one way function is included in the certificate 
or a path through a hash tree whose root is included 
in the credential. 

97. A system as in claim 93 wherein the credential in- 
cludes data specifying the types of operations for 
which the user is authorized, or the time at which 
the credential was issued or the time at which the 
credential expires. 
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